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(54) System and method for executing verifiable programs with facility for using non-verifiable 
programs from trusted sources 



(57) A computGr system includes a program execut- 
erthat executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non -verifiable program is indirectly 
verifiable by way of a digital signature on the non-veri- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures. 
Including one by the compiling party and one by the 



connpiler. Each digital signature includes a signing party 
identifier and an encrypted message. The encrypted 
message includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the signing party. A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
publk: key so as generate a decrypted message, gen- 
erating a iesi message by exucuung luu preuefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 



CM 
< 

f 

00 



f: BEST AVAILABLE COPY 



o 

Q. 



Prftitedby Jouve. 75001 PARIS (FR) 



EP 0 778 520 A2 



Description 

The present invention relates generally to distributed computer systems, and particularly to a system and method 
in which a program interpreter for programs whose Integrity Is verifiable includes a facility for using non-verifiable 
s programs from trusted sources and for refus'ng to executed other non-verif lable programs. 

BACKGROUND OF THE INVENTION 

The term "architecture" is defined for the purposes of this document to mean the operating characteristics of a 

10 family of computer models. Examples of distinct architectures are: Macintosh computers, IBM PC compatible computers 
using the DOS or Windows operating systems, SUN Microsystems computers running the Solaris operating system, 
and computer systems using the Unix operating system. 

The term "architecture neutral" is defined for the purposes of this document to refer to ability of certain programs, 
such as programs written in the Java (a trademark of Sun Microsystems, Inc.) language, to be executed on a variety 

IS of computer platforms using a number of different computer architectures. 

The term 'architecture specific" is defined for the purposes of this document to refer to requirement that certain 
programs to be executed only on computer platforms using a single computer architecture. For instance, object code 
programs written in the 60486 assembler language can only be executed on computers using the IBM PC compatible 
computer architecture (as well as in other computers that (contains IBM PC compatible computer emulators). 

^0 Important features of architecture neutral programs (ANPrograms) Include the architecture independence of pro- 
grams written in the afchitecture neutral language (ANLanguage). For example, Java bytecode programs can be ex- 
ecuted on any computer platform having a Java bytecode interpreter An additional inrportant feature of Java bytecode 
programs is that their integrity can be directly verified prior to execution by a Java bytecode verifier. A Java bytecode 
verifier determines whether the program conforms to predefined integrity criteria. Such criteria include operand stack 
and data type usage restrictions that ensure that Java bytecode programs cannot overflow or underfk>w the executing 
computers operand stack and that all program Instructions utilize only data of known data types. As a result, a Java 
bytecode program cannot create object pointers and generally cannot access system resources other than those which 
the user has explicitly granted it piermlssion to use. 

Unfortunately, distributing executable programs in an ANLanguage causes the ANProgram to run less efficiently 

30 than It would if it could take advantage of architecture specific features. For example. Java bytecode programs executed 
by a Java bytecode Interpreter typically run 2.5 to 5 times as slow as the equivalent architecture specific programs 
(ASPrograms) compiled in corresponding architecture specific languages (ASLanguages). While a factor of five speed 
reduction is actually considered to be unusually good for an ANProgram executer (i.e., interpreter), it is a sufficient 
loss of efficiency that some users will require or Insist upon the ability to use equivalent programs compiled in an 

3S ASLanguage. 

Compilers that can compile an ANProgram into an equivalent ASProgram can be wriiien. However, ihey rriay be 
prohibitively expensive for the end user. In additkxi, the integrity of the equivalent compiled ASProgram cannot be 
verified directly from the compiled ASProgram code by an ANProgram Integrity verifier. Thus, in the case of Java 
bytecode programs, the use of ANPrograms compiled into equivalent ASPrograms potentially results in the loss of one 

40 ofthenrtostvaluablefeaturesof an ANLanguage. 

However, there are some legitimate (or legal) tasks that can be performed by integrity non-verlfiable ASPrograms 
but which cannot be performed by integrity verifiable ANPrograms. These Include tasks that would otherwise violate 
the operand stack and data type usage restrictions Imposed on the integrity verifiable ANPrograms, In addition, such 
ASPrograms can be executed much faster than ANPrograms. As a result, there are number of reasons why it Is de- 

4S slrable to have a computer system that Is designed to primarily execute integrity verifiable ANPrograms but also has 
the capability of executing integrity non-verlfiable ASPrograms. 

Although compilation of ANPrograms by a third party is possible, such compilations require that the third party be 
authenticated. That is, it must be possible to verify from the Information in the compiled ASProgram that It was conrtpiled 
by a specific trusted third party. Even better. It should also be possible to authenticate that the compiled ASProgram 

so was generated by a specific trusted compiler. And, since the integrity of the compiled ASProgram with respect to 
predefined integrity criteria cannot be directly verified, the compiled ASProgram should include information that in a 
verifiable manner identifies the corresponding ANProgram from which It was compiled and the ASLanguage in which 
It was compiled. 

Embodiments of the present invention provide an ANProgram compiler arKl compilation method that enables the 
ss user of an ASProgram compiled from a con-esponding ANProgram to authenticate the identify of who compiled the 
ANProgram, the ident ity of the corresponding ANProgram, and the ASLanguage in which the ASProgram was compiled. 

Embodiments of the present invention also provide an ANProgram executer and execution method that enables 
integrity verifiable ANPrograms being executed to call integrity non-verifiable ASPrograms that are trusted or that have 
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verifiable sources and compilation information so that essentially all legitimate tasks can be performed, while preventing 
from being called ASPrograms whose sources, compilation infornr^atibn, and integrity cannot be verified. 

SUMMARY OF THE INVENTION 

In summary, the present invention is a program executer that executes verifiable architecture neutral programs, 
and a class loader that prohibits the loading and execution of non-verlflable programs unless (A) the non-verifiable 
program resides In a trusted repository of such programs, or (B) the non-verifiable program is indirectly verifiable by 
way of a digital signature on the non-verifiable program that proves the program was produced by a trusted source. 

In the preferred embodiment, each verifiable program is an architecture neutral program embodied in an object 
class having a digital signature that includes a message digest uniquely associated with that program. 

Non-verifiable programs are embodied in object classes that contain a keyword Indicating that the program (called 
a method) is not a verifiable program. In the preferred embodiment the non -verifiable programs are generally archi- 
tecture specific compiled program generated with the assistance of a compiler. Each such object class includes: 

the compiled, architecture specific code; 

if there is a corresponding architecture neutral program (which sometimes there is not), information identifying the 
corresponding architecture neutral program. Including a copy of the message digest of the corresponding archi- 
tecture neutral program; 

a digital signature by the trusted 'compiling party" that generated the object class (e.g. , by perf orrning a compilation 
of a source program), signed using the compiling party's private encryption key; and . if the code in the object class 
was generated by a compiler, a digital signature by the compiler itself, signed using the compiler's private encryption 
key. 

A generally available, trusted repository of public encryption keys, sometimes called a naming sen^ice, holds the 
public keys for the compiler and the trusted compiling party Using these public encryption keys all recipients of the 
object classes having non-verifiable programs can decrypt the digital signatures in the object class to verify that the 
object class was created by a trusted party, to verify that the non-verifiable program code in the object class was 
generated by the indicated compiler (if any), and also to verify the identity of the corresponding architecture neutral 
program (If any). Optionally, when the non-verifiable program code In the object class has a corresponding verifiable 
program, the potential user of the object class can use the program verifier to verify the proper operation of the corre- 
sponding verifiable program prior to executing the non-verifiable program code in the object class. 

BRIEF DESCRIPTION OF THE DRAWINGS 

PYAmnloc nf the in\/ontir%n u/ill nrwu ha Hae/«riKAH in rv\nitin/«ti/Mn lArith thA Hrotarinno ;*% «aiKii/<»ki«, 

, ... «,w.,j».,w„w j,^, ... ,„„WII. 

Fig. 1 is a bkx:k diagram of a distributed computer system incorporating a preferred embodiment of the present 
invention. 

Fig. 2 depicts the structure of an architecture neutral program in accordance with a preferred embodiment of the 
present invention. 

Fig. 3 depicts the structure of a compiled, architecture specific, program generated in accordance with a preferred 
embodiment of the present Inventkxi. 

Fig. 4 depicts an object and associated object class In accordance with a preferred embodiment of the present 

invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring to Fig. 1 , there is shown a computer network 100 having many client computers 102, a sender computer 
1 04, and a trusted key repository 1 06. The client computers 1 02 are connected to each other and the server computer 
104 and the trusted key repository 106 via a network communfcatbns connection 108. The network communteatlons 
connection may be a local or wide area network, the Internet, a combination of such networks, or some other type of 
network communteatioris connectbn. 

While most of the client computers 102 are desktop computers, such as Sun workstations, IBM compatible com- 
puters, and Macintosh computers, virtually, any type of computer could be a client computer. Each of these client 
computers includes a CPU 110, a user Interface 112, a memory 114, and a network communlcattons Interface 116. 
The network conrvnunications interface enables the client computers to communicate with each other, the sen/er com- 
puter 104, and the trusted key repository 108 via the network communications connection 106. 

The memory 1 1 4 of each client computer 1 02 stores an operating system 11 8. a network communications manager 
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120. an ANProgram (architecture neutral program) execuler 122. an ASProgram (architecture specific program) exe- 
cutor 124, and ANProgram integrity verifier 126, an ANProgram compiling preparer 128, a signature generator 1 30. a 
signature verifier 132, a compiling information (Complnfo) verifier 134, an object class loader 136, a qser address . 
space 138, a trusted object class repository 140. an untrusted object class repository 142, and lists l44 of known. 
s trusted compiling parties and trusted compilers. The operating system is run on the CPU 110 and controls and coor- 
dinates running the programs 1 20-1 36 on the CPU in response to commands issued by a user with the user interface 
112. 

The ANProgram executer 122 of each client computer 102 executes ANPrograms in the object classes stored in 
the trusted and untrusted object class repositories 140 and 142. Moreover, the ANProgranns are written in an ANLan- 
10 guage for which the user may establish predefined integrity criteria, such as stack and data usage restrctbns. so that 
the ANPrograms will not perform illegal tasks. Thus, the integrity of the ANPrograms can be directly verified by the 
ANProgram Integrity verifier 126 prior to execution by determining if the program satisfies the predefined Integrity 
criteria. These ANPrograms are therefore considered integrity verifiable ANPrograms. 

In the preferred embodiment, the integrity verifiable ANPrograms are written in the Java bytecode language. More- 
ls over, the ANProgram executer 122 and the ANProgram verifier 124 are respectively a Java bytecode program inter- 
preter and a Java bytecode program verifier that respectively execute and verify the Java bytecode programs. The 
Java bytecode verifier and interpreter are products of Sun Microsystems, Inc. 

However, each client computer 102 has an associated specific architecture for which programs may be written in 
a corresponding ASLanguage and executed by the ASProgram executer 122. The ASLanguage does not require that 
20 ASPrograms written in the ASLanguage satisfy the predefined integrity criteria of the ANLanguage. As a result, the 
ASPrograms can perform tasks that cannot be performed by the ANPrograms because they are not burdened by the 
restrictions imposed by the predefined integrity criteria of the ANLanguage. Unfortunately, however, this also means 
that their integrity cannot be directly verified by the ANProgram integrity verifier 126 and are therefore considered 
integrity non-verifiable. 

2S Nevertheless, as indicated earlier, an ANProgram runs less efficiently than the same program compiled in an 

ASLanguage. Thus, the user of a client computer 102 may wish to have an ANProgram compiled by the server computer 
104 for the ASLanguage associated with the user's client computer so the compiled ASProgram can be executed there 
by the ASProgram executer 124. Or, the user may wish to have the ANProgram compiled for the ASLanguages asso- 
ciated with other client computers if the compiled ASPrograms are going to be distributed and executed by the ASPro- 

30 gram executers 124 of other client computers. 

Preparing an Architecture Neutral Program for Compiling 

Referring to Figs. 1 and 2, when an originating party (OrigParty) wishes to have an ANProgram 200 compiled by 
35 the server computer 104, the OrigParty issues a command with the user interface 11 2 to invoke the ANProgram com- 

M 4 no ^..^ u 4^ .^.^^^-.^ 4t- ... a ktrt...^...^^ •ri-^ mhtn-^. ^ u _ .1 

^iiii 1^ pi oyatvi aiiu ii loii u^i u i\j pi cpciic u lo rMiri w^iaii i lAJi I ipiiii ly. 1 1 ic rvi>ir lu^iai II may II I till UUjUUl UI<:Si>$> 

contained in one of the trusted or untrusted object class repositories 140 or 142. Table 1 contains a pseudocode 
representation of the procedure used by the ANProgram compiling preparer 128 to prepare the ANProgram for com- 
piling by the server computer 1 04. The pseudocode used in Tables 1 -3 uses universal computer language conventions. 

40 While the pseudocode employed here has been invented solely for the purposes of this descriptbn. it is designed to 
be easily understandable by any computer programmer skilled in the art. 

Referring to Figs. 1 and 2 and Table 1, the ANProgram compiling preparer 128 first calls the ANProgram integrity 
verifier 126 and instructs It to verify the integrity of the ANProgram code 202 of the ANProgram 200. This is done to 
make sure that the ANProgram code satisfies the predefined integrity criteria of the ANLanguage prk>r to being sent 

45 to the sender computer 104 for compiling. If the ANProgram code does not satisfy the predefined integrity criteria, the 
AN Program Integrity verifier sends back a failed result to the ANProgram compiling preparer In response, the AN- 
Program compiling preparer aborts the compiling preparatbn procedure and generates an appropriate message indi- 
cating this. 

However, If the ANProgram code 202 does satisfy the predefined integrity criteria, then the ANProgram integrity 
50 verifier 1 26 sends back a passed result to the ANProgram compiling preparer 1 28. The ANProgram compiling preparer 
then calls the signature generator 1 30 and instructs it to generate the OrigPart/s digital signature (Digitals ignature^p) 
210 that can be verified to ensure that the ANProgram 200 was generated by the trusted OrigParty. The signature 
generator generates the DigitatSignatureop by first generating a message digest (MDqp) 212 of the ANProgram code 
202. It does this by computing a hash function, HashFunctlonop. on the data bits of the ANProgram code. The hash 
55 function used may be either a predetermined hash function or one selected by the OrigParty For purposes of this 
document, the HashFunctkx^^p corresponds to the OrigParty since it was used for the DigltalSignatureop of the Orig- 
Party. 

The signature generator 130 then encrypts the generated massage digest (MDqp) 212 and the ID of the Hash- 
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Functionop (HashFunctioriop ID) 214 with the private encryption l^ey of the OrigParty (OrigParty's PrivateKey). The 
signature generator then adds the OrigPart/s ID 216 in clear text at the end of the encrypted items 212 and 214 to 
form the DigitalSignatureop. The OrigParty's PrivateKey and ID are provided by the OrigParty with the user interface 
112. I 

After the DigitalSignatureop 21 0 is generated, the ANProgram compiling preparer 1 28 appends it to the ANProgram 
code 202. Then, the ANProgram compiling preparer generates a message that the ANProgram 200 has been prepared 
for compiling by the server computer 1 04. 

The OrigParty then issues with the user interface 112 a command to the network communications manager 120 
to transmit the ANProgram 200 to the sender computer 1 04, along with arguments specifying the architecture specific 
language into which the program is to be compiled (ASLanguage ID) and the compiler to be used (Compiler ID). The 
network communications manager retrieves the ANProgram from the trusted or untrusted object class repository 1 40 
or 1 42 in which it is located and provides it to the network communications Interface 1 1 6. The network communications 
manager then instructs the network communteatlons interface to transmit the ANProgram to the server computer along 
with the specific arguments. 

Compiling an Architecture Neutral Program 

The transmitted ANProgram 200 is then received at the server computer 104. The server computer includes a 
CPU 1 50, a user interface 1 52, a memory 154, and a network communications Interface 156. The network communi- 
cations interface enables the server computer to communicate with the client computers 102 and the trusted key re- 
pository 106 via the network communteatbns connectton 108. 

The memory 1 54 of the server computer 1 04 stores an operating system 1 58, a network communications manager 
160, an ANProgram compiler 162. a signature verifier 164, an ANProgram integrity verifier 166. a signature generator 
168, an ANProgram repository 170. and an ASProgram repository 172. The operating system is run on the CPU 160 
and controls and coordinates running the programs 160-168 on the CPU in response to commands issued by a com- 
piling party (CompParty) with the user interface 152. 

The network communications-interface 156 receives the ANProgram 200 and instructs the network communica- 
tions manager 160 that this has occurred. In response, network communications manager places the received ANPro- 
gram in the ANProgram repository 170. It the server 104 is set up as an automatic compiler sewice. this is done 
automatically by the network communications manager 160. Otherwise, the ANProgram is moved into repository 170 
by the network communteations manager when the CompParty issues a command with the user interface. 

Then, either automatically, or upon the issuance of a command by the CompParty with the user interface 252, the 
ANProgram compiler 162 is invoked to compile the ANProgram 200. Table 2 contains a pseudocode representation 
of the compilation procedure used by the ANProgram compiler to compile the ANProgram. 

Referring to Figs. 1-2 and Table 2, the ANProgram compiler 162 first calls the signature verifier 164 to verify the 
DiqitalSignatureQp 210 in the received ANProaram 200 ro as to establish that the Dl'^ltalSi'^nati 
the originating party's signature for the ANProgram (e.g., as opposed to being a forged signature or the OrigParty 
signature on some other version of the ANProgram), In particular, the signature verifier uses the ClearText OrigParty's 
ID 216 in the received ANProgram to obtain the OrigParty's PublicKey from the trusted key repository 106. Then the 
signature verifier decrypts the encrypted MDqp 212 and HashFunctionoR ID 214 in the DigitalSignatureop "sing the 
public encryption key of the OrigParty (OrigParty's PublicKey). 

Next, the signature verifier 164 generates a test message digest (TestMDop), which should match the decrypted 
MDqp 21 2. by computing the corresponding HashFunctlonop on the ANProgram code 202 of the received ANProgram 
200. The HashFunctlonop ID 214 in the decrypted DigitalSignatureop ^ "sed to identify the proper HashFunctlonop 
to be used. The decrypted MDqp and the generated TestMDop are then compared to verify the DigitalSignatureop 21 0. 

If the MDqp 212 and the TestMDop do not match, then the signature verifier 162 sends back a failed result to the 
ANProgram compiler 162. In response, the ANProgram compiler aborts the compiling procedure and generates an 
appropriate message. 

On the other hand, if the MDop and the TestMDop do match, then the signature verifier 162 sends back a passed 
result to the ANProgram compiler 162 and the ANProgram compiler calls the ANProgram Integrity verifier 166. It In- 
structs the ANProgram integrity verifier to verify the integrity of the ANProgram code 202 of the received ANProgram 
200. This Is done in the same manner and for the same purpose as was described eariier in the section discussing 
preparing the ANProgram for compiling. Thus, if the ANProgram code does not satisfy the predefined integrity criteria, 
the ANProgram integrity verifier sends back a failed result to the ANProgram compiler. In response, the ANProgram 
compiler aborts the compiling procedure and generates an appropriate message indicating this. 

However, if the ANProgram code 202 of the received ANProgram 200 does satisfy the predefined integrity criteria, 
then the ANProgram integrity verifier 1 66 sends back a passed result to the ANProgram compiler 1 62. The ANProgram 
compiler then compiles the ANProgram code into the ASl-anguage identified by the ASLanguage ID specified by the 
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OrigParty. Referring now to Figs. 1-3 and Table 2. the compiler places the ANProgram code 202, the DigitalSignatureop 
210 and the compiled ASProgram code 302 in an ASProgram 300 that is stored in the ASProgram repository 172. 

The ANProgram compiler 162 then calls the signature generator 168 and instructs it to generate the ANProgram 
compiler's digital signature (DigitalSignaturec) 320 which can be verified to ensure that the ASProgram 300 was com- 
piled with the trusted ANProgram compiler. This is done in a manner similar to that described earlier for generating the 
DigitalSignatureop. However, in this case, the set of information signed is the ASProgram code and the DigitalSigna- 
tureop. Another predetermined hash function with a corresponding HashFunctionc ID 324 may be used to generate 
the message digest MDc 322 of the set of infomnation to be signed by the DigitalSignaturec, the private "encryption 
key of the ANProgram compiler (Compiler's PrivateKey) is used to encrypt the MDc and the HashFunctionc ID. and 
the identifier of the ANProgram compiler (Compiler's ID) is added in clear text at the end of the encrypted MDq and 
HashFunctionQ. The Compiler's PrivateKey and ID are provided by the ANProgram compiler. 

The ANProgram compiler 162 calls the signature generator 168 a second time to generate the CompParty's digital 
signature (DigitalSignaturecp) 312, which can be verified by end users to ensure that the ASProgram 300 was gener- 
ated by the trusted CompParty. This is done in a similar manner to that described earlier for generating the DigtialSig- 
natureop (in the section discussing preparing an ANProgram for compiling). However, here the message digest (MDcp) 
31 4 generated for the DigitalSignaturecp is generated by computing a predetermined or selected hash function (Hash- 
Functioncp) on the data bits of the ASProgram code, the DigitalSignatuerQp and the DigitalSignaturec. Sirnilar to the 
HashFunctionop, for purposes of this disclosure, the HashFunctloncp corresponds to the CompParty since it was used 
for the DigitalSignaturecp of the CorripParty. 

The signature generator 1 68 then encrypts the MDcp 31 4 and the ID of the HashFunctioncp (HashFunctloncp 'D) 
316 with the private encryption key of the CompParty (CompParty's PrivateKey). The signature generator then adds 
the identifier of the CompParty (CompParty's ID) 318 in clear text at the end of the encrypted items. 314 and 316 to 
form the DigitalSignaturecp 312. The CompParty's PrivateKey and ID are provided by the CompParty with the user 
intertace 152. 

After the DigitalSignaturec 320 and the DigitalSignaturecp 312 are generated, the ANProgram compiler 162 ap- 
pends them to the ASProgram code 302. so that the resulting compiled ASProgram file or object has the following 
components in it: 

ANProgram Code, 
DigitalSignaturecp. 
ASProgram Code, 
DigitalSignaturec. and 
DigitalSignaturecp 

Then, the ANProgram compiler generates a message that the ANProgram 200 has been compiled to form the ASPro- 
gram 300 ?tnd Is r^ady to be sent to the Ori'^Psrt**. 

The CompParty then uses the network communications manager 160 to transmit the ASProgram 300 to the Orig- 
Party's client computer 102. The network communications manager does so by retrieving the ASProgram from the 
ASProgram repository 172 In whteh it is located and provkles It to the network communications interface 156. The 
network communbations manager than instructs the networic communications Intertace to transmit the ASProgram to 
the OrigParty's client computer. 

Object and Object Class Creation and Distrlbutk)n 

The transmitted ASProgram 300 is then received by the communications Interface 116 of the OrigParty's client 
computer and instmcts the network communications manager 120 that this has occurred. In response, the OrigParty 
issues a command with the user Intertace 252 to instruct the network communications manager to retrieve the received 
ASProgram from the network communlcalbns interface, causing the network communications manager to place the 
received ASProgram in the untrusted object class repository 142 of the OrigParty's client computer. Once this is done, 
the OrigParty may treat the received ASProgram as a new object class with just one method (i.e. the compiled program 
code), or it rr^y create an object class that includes the ASProgram 300 as well as other ANPrograms and ASPrograms. 

Fig. 4 shows a typical object class 400 in accordance with the present invention. The object class may include one 
or more ASPrograms 402 and/or one or nr>ore ANPrograms 404. as well as a virtual functfon table 410. For each 
ASProgram. the virtual function table contains a corresponding identifier (native^AS Prog ram ID) 412 that indicates 
that it is an ASProgram (i.e., a native program) that is not in the ANLanguage and a corresponding pointer (Ptr) 414 
to the native program. Similarly, for each ANProgram, the virtual function table contains a corresponding identifier 
(ANProgram ID) 416 and a corresponding pointer 418 to the ANProgram. Every object 420 of this object class includes 
an object header 422 that points to the object class 400. 
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. Thus, the OrigParty may create an object 420 and an object class 400 with the ASProgram 300 that was received 
from the server computer 104 as one of the ASPrograms 402 in the object class. 

When the OrigParty wishes to distribute to various ExecuteParties an object and object class that includes the 
ASProgram 300 and ANProgram, then the OrigParty issues a connmand with the user interface 112 to instruct the 
network communications manager to transmit these Items to the client computer 1 02 of the ExecuteParties. The network 
communications manager does this by retrieving them from the untrusted object class repository 142 In which they are 
located and provides them to the network communications interface 116 with appropriate transmission instructions. 
Alternately, the network communications manager of the OrigParty nnay respond to a request initiated by an Exe- 
cuteParty for a copy of a specified object class 400. 

Execution of Architecture Neutral Programs and Architecture Specific Programs in an Object Class 

The network communications interface 156 of the client computer 102 receives the transmitted object and object 
class and instructs the network communications manager 160 that this has occurred. In response, the ExecuteParty 
issues a command with the user Interface 1 1 2 to instruct the network communications manager to retrieve the received 
object and object class from the network communications interface. The network communications manager then stores 
the received object and object class In the untrusted object class repository 142. 

The untrusted object class repository 142 of each client computer 102 contains the objects and their associated 
object classes that are not trusted. These object classes are not trusted because any ANPrograms they Include have 
not yet had their integrity verified and any ASPrograms they include have not had their source verified nor have been 
verified as being compiled from the proper ANProgram. 

The trusted object class repository 140 of each client computer contains the objects and their object classes that 
are trusted. These object classes are trusted because any ANPrograms they include may have already had their 
Integrity verified by the ANProgram integrity verifier 1 36 and any ASPrograms they contain have been ascertained to 
be trustworthy In fact, some or all the object classes in the trusted object class repository 140 need not have digital 
signatures, because these object classes are trusted and therefore there Is no reason to perfomr* Integrity chocks on 
the methods in these object classes. 

It is desirable to have an object class that primarily includes ANPrograms but may also include ASPrograms so 
that essentially all legitimate tasks can be performed with the object class, as suggested earlier Therefore, the AN- 
Program executer 122 is capable of executing integrity verifiable ANPrograms and calling the ASProgram executer to 
execute integrity non-verifiable ASPrograms that are either (1) in trusted object classes in the trusted object class 
repository 1 40, or (2) that are in untrusted object classes in the untrusted object class repository 1 42 and have verifiable 
DigltalSignatureop. DigitalSlgnaturecp and DigitalSignaturec infomnation so that essentially all legitimate tasks can be 
performed. In this way, ASPrograms of untrusted object classes that don't have DigltalSignatureop, DigitalSlgnaturecp 
and DigitalSignaturec information or whose digital signatures cannot be verified are prevented from being execiited. 
Table 3 contains a pseudocode representatbn of the execution procedure used by the ANProgram executer. 

Referring to Figs. 1-4 and Table 3. at the client computer 102 of an ExecuteParty (e.g., the OrigParty or another 
party), the ANProgram executer 1 24 may be executing an ANProgram that seeks to call a method in a specified object 
class. The method call Is initially handled by the object class loader 136. which determines whether or not the object 
class has already been loaded. If the object class has already been loaded into the ExecuteParty's user address space 
138, then the ANProgram executer 122 executes the called method if the called method Is an ANProgram and the 
ASProgram executer 124 executes the called method if the called method Is an ASProgram. 

However, If the object class has not yet been loaded into the ExecuteParty's address space 138, then the object 
class loader 1 36 loads the object class into the ExecuterParty's address space and determines whether or not execution 
of the called method is to be allowed. For instance, if the object class was loaded from the trusted object class repository 
140, then execution of the called method Is permitted and the Execute procedure is called. The Execute procedure 
(see Table 3) calls the ANProgram executer if the called method Is an ANProgram. and othenwise calls the ASProgram 
executer 1 24 to execute the called method. 

However, if the object class was toaded from the untrusted object class repository 142, the class loader 136 ex- 
amines the object header of the object to determine if its object class includes any ASPrograms. It does so by deter- 
mining if there any native_ASProgram IDs in the virtual functton table of the object. 

If there are no ASPrograms in the object class, then the class loader 136 calls the ANProgram integrity verifier 
136 to verify the integrity of the ANPrograms in the object class. This is done in the same manner and for the same 
purpose as was described earlier for verifying the integrity of the ANProgram 200 (in the section discussing compiling 
an ANProgram). Thus, if the integrity of any of the ANPrograms is not verified, then the ANProgram integrity verifier 
passes back to the class loader a failed result and the class loader aborts the class loading procedure and generates 
an appropriate message Indicating this. But, If the ANProgram integrity verifier sends back a passed result indicating 
that all of the ANPrograms of the object class are verified, the class loader enables execution of the called method. 



BEST AVAIUBLE COPY 



EP0 778 520 A2 



If there are any ASPrograms in the object class, then the class loader 1 36 calls the signature verifier 1 32 to verify 
the compiler signature DigitalSignaturec and the ConnpParty signature DigitalSignatureop. If any of the ASPrograms 
does not Include a DigitalSignaturec p and a DigitalSignaturec. the Integrity of the ASProgram's source cannot be 
verified and therefore the signature verifier sends back to the ANProgram executor a failed result. In response, the 
class loader aborts the object class loading procedure and generates an appropriate message that this has occurred. 

Further, if all ot the ASPrograms in the object class do Include a DIgitaSignaturecp and a DigitalSignaturec, the 
Identities of the CompParty and the Compiler as indicated in these two digital signatures, are compared with the lists 
1 44 (see Fig. 1 ) of known, trusted Compiler Parties and trusted Compilers. If any of the ASPrograms in the object class 
were compiled by a CompParty or a Compiler not included In the set of known, trusted Compiler Parties and trusted 
Compilers, the class loading procedure is aborted, and execution of the called method is thereby blocked. Similarly, if 
the ASLanguage identified in any of the ASPrograms does not match the ASLanguage used by the ASProgram Exe- 
cuter 1 24, the class loading procedure is aborted. 

However, it all of the ASPrograms in the object class do include a DigitalSignaturecp a DigitalSignaturec, and 
the Identified CompParty and Compiler for all the ASPrograms are tnjsted Compiler Parties and Compilers, and the 
ASLanguage used by all the ASPrograms is one used by the ASProgram Executer, then the signature verifier verifies; 
these signatures in a similar manner as was described earlier for verifying the DigltalDignatureop (in the section dis 
cussing compiling the ANProgram 200). However, In this case, the Compiler's and CompPart/s public keys are re- 
trieved from the trusted key repository 106 and respectively used to decrypt the MDc and HashFunctlonc ID In the 
DigitalSignaturec MDcp and the HashFunctioncp in the DigitalSignaturecp. Furthermore, the test message 

digests (TestMDc and TeslMDcp) corresponding to the decrypted MDcp and MDc generated by computing hash 
codes on the data bits of the ASProgram code plus the DigitalSignatureop for the TestMDc and on the same data bits 
plus the DigitalSignaturec for the TestMDcp. according respectively to the HashFuncliooc and HashFunctioncp 
tified by the decrypted HashFunctkjnc ID and HashFunctioncp ID. 

if the DigitalSignaturec and/or the DigitalSignaturecp verified (i.e., MDc # TestMDc and/or MDcp # TestMDcp) 
for every ASProgram, then the signature verifier 136 sends back to the class loader 136 a failed result. In response, 
the class loader aborts the class loading procedure and generates an appropriate message that this has occurred. 

However, If the DigitalSignaturec the DigitalSignaturecp are both verified (i.e.. MDc = TestMDc MDcp = 
TestMDcp) for every ASProgram, then the ANProgram executer 124 again calls signature verifier 132 to verify the 
OrigPart/s signatures (DIgltaSlgnatureop) for the ANPrograms from whfch the ASPrograms were compiled. To verify 
the OrigParty digital signatures, the DigitalSignatureop of each is verified In the same manner as was discussed earlier 
in the section conceming compilation of the ANProgram 200. 

If the DigitalSignatureop of each of the ANPrograms from which the ASPrograms were compiled is verified, then 
the class loader calls the ANProgram integrity verifier to verify the integrity of every ANProgram in the object class and 
the ANPrograms from whteh the ASPrograms were compiled. This is done in the same manner as was described 
earlier. If the Integrity of any of these ANPrograms Is not verified, then the ANProgram integrity verifier sends back to 
the class loader a failed result, which aborts the class loading procedure and generates an appropriate message. 

nowever, if ihe iniegriiy of each of the ANPrograms is verified, then the ANProgram integrity verifier 126 sends 
back a passed result to the class loader 136. In response, the class bader invokes the ANProgram executer or AS- 
Program executer to execute the called method, as appropriate. 

In view of the foregoing, the ExecuterParty Is assured that only those untrusted object classes in the untrusted 
repository 142 that have integrity verifiable ANPrograms and ASPrograms whose digital signatures can be verified will 
be k}aded and have their programs executed. 

Altemative Embodiments 

Some of the features of the invention described above are optional. Thus, those skilled in the art will recognize 
that altemative embodiments exist that don't Include these features. 

For example, the ANProgram compiler has been described as generating both a DigitalSignaturecp and a Digital- 
Signaturec respectively for the CompParty and the ANProgram compiler. However, the ANProgram compiler could be 
constructed simply to generate only one of these digital signatures for enabling verification of the either the compiler 
used to compile the ASProgram or the compiling party. 

Simllariy, the program executer has been described as requiring verification of both a DigitalSignaturecp and a 
DigitalSignaturec- However, the program executer could be constructed to require verlficatton of only one of these 
digital signatures and opttenally verify the other digital signature if the ASProgram being verified includes it. Further- 
more, the program executer could be constructed to skip the step of verifying the integrity of the ANProgram corre- 
sponding to each ASProgram, based on the assumption that the compiling party is trusted and that It is a duty of the 
compiling party to verify the integrity of each ANProgram that is compiles into an ASProgram pror to performing the 
compilatk>n. 
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When the ExecuterParty is the OrigParty. the ExecuterParty knows that ft actually sent the ANProgram 200 to the 
CompParty's server computer 104 to be compiled into the ASProgram 300. In this case, the class loader 136 could be 
constructed to not call the signature verifier to verily the DigtialSignatureop in the ANProgram, Rather, the Executer- 
Party can simply compare the DigtialSignatureop in the local copy of the ANProgram with the DigtialSighatureop in • 
the compiled ASProgram. Additionally, the class loader could be constructed to not call the AN Program integrity verifier 
1 26 to verify the integrity of the ANProgram corresponding to a called ASProgram since the integrity of the ANProgram 
would have been checked during the preparation for compiling procedure prior to being sent to the compiling server 
computer. Alternatively, the ANProgram compiling preparer 1 28 could be constructed to not call the ANProgram integrity 
verifier during the preparation for compiling procedure since its integrity would be checked both by the compiler and 
when the class loader calls the ANProgram integrity verifier prior to execution of the corresponding ASProgram. 

TABLE 1 

Pseudocode Representation of Method of Preparing Architecture 
Neutral Program for Compiling 

Procedure: Prepare for Compiling (ANProgram code, OrigParty's PrivateKey, and 
OrigParty's ID) 
{ 

Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ abort and generate failed result message } 
Generate MDqp = HashFunctionop (ANProgram code) 
Generate DigitalSignatureop = Encrypt (MDqp + HashFunctionop ID. OrigParty's 

PrivateKey) + ClearText (OrigParty's ID) 
Append DigitalSignatureop to ANProgram code 
Generate message that ANProgram is prepared for compiling 
Return 
} 
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g Pseudocode Representation of Method of Compiling ANProgram and 

Generating ASProgram 

Procedure: Compile (ANProgram. CompPart/s ID. ASI^nguagelD, CompPart/s 
jf, PrivateKey, Compiler's ID, and Compiler's PrivateKey) 

{ 

Retrieve OrigPart/s PublicKey from trusted Key repository using ClearText 
OrigPart/s ID in DigitalSignatureop 
,5 Decrypt (MDqp + HashFunctlonop ID in DigitalSignatureop. OrigPart/s 

PublicKey) 

Generate TestMDop = HashFunctlonop (ANProgram code) using 
HashFunctionop identified by decrypted HashFunctlonop ID 
20 Compare decrypted MD^p and TestMDgp 

If decrypted MDqp «» TestMDop 
{ 

r DigitalSignatureop of OrigParty not verified */ 
ss Generate failed result message 

} 

Else 

{ 

30 I* DigitalSignatureop of OrigParty has tieen verified */ 

Verify Integrity of ANProgram with ANProgram integrity verifier 
if failed result 

{ 

^ abort and generate failed result message 

} 

Else 

{ 

^ /• ANProgram has been verified */ 

Compile ANProgram code into ASLanguage Identified by 

ASL^nguage ID to generate ASProgram code 
Generate MDc = HashFunctioncs (ASProgram code + 

DigitalSignatureop) 
Generate DigitalSignaturec = Encrypt (MDc + HashFundionc ID. 
ANProgrom Compiler's PrivateKey) + ClearText 
ANProgram Compiler's ID 
Generate MDgp = HashFunctionop (ASProgram code + 

DigitalSignatureop + DigitalSignaturec) 
Generate DigitalSignaturecp = Encrypt (MDcp + HashFunctioncp 
ID, CompParty-s PrivateKey) + aearText CompParty's ID 
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Generate and Return File or Object containing: 

ANProgram Code. 

DigitalSignatureop, 

ASProgram Code. 

DigitalSignaturec, and 

DigitalSignaturecp 
/• ASProgram has been conrtpHed and generated */ 

) 

} 

} 
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TABLES 

5 Pseudocode Representation of Method of Executing 

Architecture Specific Program 

Procedure: Execute (ObjectClass, Program) 

10 [ 

If the Program is a verifiable program 

( Execute Program using the Bytecode Interpreter) 
Else 

{Execute Program using the compiled program executer) 

} 

Procedure: ClassLoad (ObjectClass, Program) 

20 ^ " 

If Object Class has already been loaded into ExecuterPart/s address space 
{ 

Call Execute (ObjectClass. Pn)gram) 
Retum 

} - 

^ r The Object Class has not been loaded V 

Load Object Class into ExecuterPart/s address space 
If Object Class was loaded from Trusted Object Class Repository 
{ 

35 Call Execute (ObjectClass, Program) 

Retum 

} 

40 /* Object Class was loaded from Untrusted Object Class Repository */ 

If Object Class does not contain any ASPrograms designated as 
native_ASPrograms in Object Header of Object 
{ 

^ Verify integrity of all ANPrograms of Object aass with ANProgram integrity 

verifier 
If failed result 
{ 

Abort with appropriate failed result message 
} 

Else 

r Integrity of all ANPrograms of Object Class have been verified */ 
^ { Call Execute (ObjectClass, Program) } 
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Return 
} 

r Object Class does contain ASPrograms designated as native_ASPrograms in 

Object Header of Object •/ 
If any ASProgram does not contain a DigitalSlgnaturecp and a DigltalSignaturec 

{ 

/* Compiling Party and Compiler of every ASProgram cannot be verified */ 

Generate appropriate message 

Return 

} 

For each ASProgram in Object Class: 

{ Determine identity of CompParty and Compiler and determirie 
ASLanguage used by ASPrograrp } 
If identity of CompParty for any ASProgram is not a known, trusted, Compiling 

Party, or the identity of Compiler is not a known, trusted Compiler, or the 

identified ASLanguage is not one used by the ASProgram Executer 

{ 

Generate appropriate message 

Return 

} 

For each ASProgram in Object Class: 
{ 

Retrieve CompParty's PubfcKey from tmsted key repository using ClearTexl 

CompPart/s ID in DigitalSignaturecp 
Decrypt (iWDcp + HashFunctioncp iD in DigitalSignaturecp, CompParty's 

PubllcKey) 

Generate TestMDcp = HashFunctioncp (ASProgram code + DigitalSignaturOoF 
+ DigltalSignaturec in ASPn^gram) using HashFunctioncp Wentified by 
decrypted HashFunctioncp ID 

Compare decrypted MDcp and TestMDcp 

) 

If decrypted MDcp * TestMDcp for any ASProgram 
{ 

r DigitalSignaturecp for every ASProgram has not been verified */ 

Generate appropriate failed result message 

Return 

} 

I* DigitalSignaturecp for every ASProgram has been verified*/ 
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For each ASProgram in Object Class: 

{ 

^ Retrieve ANProgram Compiler's PublicKey from trusted key repository using 

ClearText ANProgram Compiler's ID In DigitalSignaturec 

Decrypt (MD^ + HashFunctionc ID in DigitalSignaturec. ANProgram 
Compiler's PublicKey) 

Generate TestMDc = HashFunctionc (ASProgram code + DigitalSignatureop) 
using HashFunctionc identified by decrypted HashFunctionc ID 

Compare decrypted MDc and TestMDc 

} 

,^ If decrypted MD^ * TestMDc for any ASProgram 

{ 

/* DigitalSignaturec for every ASProgram In Object Class has not been 
verified */ 

20 Generate appropriate failed result message 

Return 
} 

2s I* DigitalSignaturec for every ASProgram In Object Class has been verified */ 

For each ANProgram from which an ASProgram in Object Glass was compiled: 

{ " 

Retrieve OrigPart/s PublicKey from tmsted key repository using ClearText 
30 OrigPart/s ID in DigitalSignatureop 

Decrypt (MDqp + HashFunctionop ID in DigitalSignatureop, OrigPart/s 
PublicKey) 

Generate TestMDop = HashFunctionop (ANProgram code) using 
3s HashFunctionop identified by decrypted HashFundionop ID 

} 

If decrypted MDqp # TestMOgp for any ANProgram 

40 [ 

r DigitalSignatureop for every ANProgram from which an ASProgram In 

Object Class was compiled not verified */ 
Generate failed result message 
^ Retum 

} 

r The DigitalSignatureop every ASProgram in Object Class is verified •/ 
Verify Integrity of ANPrograms in Object class and ANPrograms from which 

ASPrograms In Object Qass were compiled with ANProgram Integrity verifier 
If ^ed result 

{ 
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Generate failed result message 
Return 

) . ' 

r Integrity of all ANPrograms in Object class and all ANPrograms from which 

ASPrograms in Object Class were compiled have been verified V 
Call Execute (ObjectClass, Program) 
) 



Claims 

1. A computer comprising: ^ 

a program integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 
defined program integrity criteria; 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an unlrusted object class repository that stores untrusted object classes; 
a trusted object class repository that stores trusted object classes; 

said object classes each including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose integrity cannot be verified 

by the integrity verifier; 

an architecture specific program executer; 

an architecture neutral program executer; 

a user address space; and 

a class loader that loads a specified one of said object classes into the user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
logic for preventing the loading of any requested object class, other than object classes in said trusted object 
class repository, that includes at least one architecture specific program unless every architecture specific 
program in the requested object class includes a digital signature and said digital signature Is successfully 
verified by said digital signature verifier. 

2. The computer ot claim 1 , said class loader includes verifier logic for invoking said program htegrity verifier to verify 
the integrity of every architecture neutral program in the requested object class when the requested object class 
is not stored in said trusted object class repository and includes at least one architecture neutral program; 

said program security logic further preventing the loading of said any requested object class other than object 
classes in said trusted object class repository when the requested object class includes at least one architecture 
neutral program whose integrity is not verified by said program integrity verifier. 

3. The computer of claim 1 , 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associated with said identified signing party; and 
said digital signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message digest, generating a 
test message digest by executing said message digest f unctbn on the architecture specific program associated 
with said digital signature, comparing said test message digest with said decrypted message digest, and is- 
suing a failure signal if said decrypted message digest and test message digest do not match. 
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4. The computer of claim 1 . 

said program security logic further tor preventing the loading of any requested object class, other than object 
classes in said trusted object class repository, that Includes at least one architecture specific program unless 
5 every archrtectu re specific program In the requested object class includes two digital signatures and said digital 

signatures are both successfully verified by said digital signature verifier; 

each said digital signature associated with one of said architecture specific programs Including a signing party 
identifier and an encrypted message, said encrypted message including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said digKal signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party Identified by sakJ signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message, generating a test 
message by executing said predefined procedure on the architecture specific program associated with said 
digital signature, comparing said test message with said decrypted message, and issuing a failure signal" if 
said decrypted message digest and test message digest do not match; and 

said program security logic preventing loading of the requested object class, other than object classes in said 
trusted object class repository, unless every architecture specific program in the requested object class In- 
cludes a first digital signature for which the signing party is a member of a first group of trusted parties, and 
includes a second digital signature for which the sigriing party is a member of a second group of trusted parties. 

6. The computer of claim 1 , 

said program security togic preventing loading of the requested object class, other than object classes in 
said trusted object class repository, unless every architecture specific program in the requested object class in- 
25 eludes a message digest for an associated architecture neutral program, and said message digest matches a test 

message digest generated by said program security logic by perfomning a predefined message digest procedure 
on said associated architecture neutral program. 

6. A method of operating a computer system, comprising the steps of: 

30 

storing untrusted object classes in an untrusted object class repository; 
storing trusted object classes in a trusted object class repository; 
. said object classes each including at least one program, each program comprising a program selected from 
the group consisting of (A) architecture neutral programs written in an architecture neutral language and (B) 
^ architecture specific programs written in an architecture specific language; 

when execution of any program in the one object class is reqi.ieeted, k>adinQ the requested object class Into 
a user address space for executk)n unless loading of the requested object class is prevented by a security 
violatbn, including preventing the toading of any requested object class, other than object classes in said 
trusted object class repository, that includes at least one architecture specific program unless every architec- 
ture specific program in the requested object class includes a digital signature and said digital signature is 
successfully verified by said digital signature verifier. 

7. The method of claim 6, said object class loading step including (A) verifying the integrity of every architecture 
neutral program in the requested object class when the requested object class is not stored in said trusted object 

45 class repository and includes at least one architecture neutral program, and (B) and preventing the loading of the 
requested object class, unless the requested object class is in said trusted object class repository, whqn the re- 
quested object class includes at least one architecture neutral program whose Integrity is not verified. 

8. The method of claim 6, 

so 



each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associated with said identified signing party; and 
said object class loading step including processing a specified digital signature by obtaining a public key as- 
sociated with the signing party identified by said signing party kJentifier, decrypting the encrypted message of 
said digital signature with said public key so as generate a decrypted message digest, generating a test mes- 
sage digest by executing said message digest f unctbn on the architecture specific program associated with 
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said digital signature, comparing said test message digest with said decrypted message digest, and Issuing 
a failure signal If said decrypted message digest and test message digest do not match. 

9. The method of claim 6, 

object class loading step Including preventing the loading of any requested object class, other thian object 
classes in said trusted object class repository, that Includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes twodlgital signatures and said digital 
signatures are both successfully verified by said digital signature verifier; 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message Including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said object class loading step including processing a specified digital signature by obtaining a public key as- 
sociated with the signing party identified by said signing party Identifier, decrypting the encrypted message of 
said digital signature with said public key so as generate a decrypted message, generating a test message 
by executing said predefined procedure on the architecture specific program associated with said digital sig- 
nature, comparing said test message with said decrypted message, and Issuing a failure signal if said decrypt- 
ed message digest and test message digest do not match. 

said object class ksading step further Including prefVenting loading of the requested object class, other than 
object classes in said trusted object class repository, unless every architecture specific program in the request- 
ed object class includes a first digital signature for which the signing party is a member of a first group of 
trusted parties, and includes a second digital signature for whtoh the signing party Is a member of a second 
group of trusted parties. 

10. The method of claim 6, 

said object class loading step including preventing loading of the requested object class, other than object 
classes in said trusted object class repository, unless every architecture specific program in the requested object 
class includes a message digest for an associated architecture neutral program, and said message digest matches 
a test message digest generated by said program security togic by performing a predefined message digest pro- 
cedure on said associated architecture neutral program. 

11. A memory for storing data programs being executed on a data processing system, said memory comprising: 

a program Integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 

Mr/^nronn inftMnriii* ^rit^rir*' 
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a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an untrusted object class repository that stores untrusted object classes; 
a trusted object class repository that stores trusted object class;es; 

said object classes each Including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose integrity cannot be verified 

by the Integrity verifier; 

an architecture specific program executor; 

an architecture neutral program executer; and 

a class loader that loads a specified one of said object classes Into a user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
instructions for preventing the k)ading of any requested object class, other than object classes in said trusted 
object class repository, that includes at least one architecture specific program unless every architecture spe- 
cific program in the requested object class includes a digital signature and said digital signature Is successfully 
verified by said digital signature verifier 

12. The memory of claim 11 , said class loader includes verifier Instructions for invoking said program integrity verifier 
to verify the integrity of every architecture neutral program In the requested object class when the requested object 
class is not stored in said trusted object class repository and includes at least one architecture neutral program; 

said program security instructions further preventing the loading of said any requested object class other 
than object classes in said trusted object class repository when the requested object class Includes at least one 
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